The present invention relates to database management system (DBMS) configurations, and more specifically to active/active DBMS configurations, where two or more DBMS are kept synchronized using log-capture/transaction replay replication technology. In such a configuration, the DBMSs are fully active and independent of each other. Database transactions do not require any locking or coordination across DBMSs. Instead, captured log records in one DBMS are transformed into data manipulation language statements that are executed at each target. Each replication Consistency Group (CG) may use a different transmission path and different replication programs, all operating in parallel, with the potential for failing independently.
An Active/Active configuration provides Continuous Availability (CA) throughout planned maintenance, outages, and disaster. Maintenance activities include system, hardware, or software upgrades, migrations, and deployments. Outages can be caused by component failure, performance degradation due to system overload. Disasters involve unrecoverable data loss, which might be caused by the loss of a site, following a catastrophe, such as a flood, earthquake, etc. In order to ensure availability, typically one or more hot failover sites are kept synchronized with a primary site using software replication and are used for switching applications during unavailability of the primary site for these applications, or following a disaster. Applications transactions can run at any site, but are generally routed to one site at a time in a manner that avoids change conflicts, particularly if and when such transactions involve monetary transfers.
Existing replication technologies often replicate data with eventual consistency semantics, transmitting and applying changes in parallel to a target. While eventual consistency may be suitable for a large number of read-only applications, this may not be the case for disaster recovery, as it under certain circumstances might leave the target in an inconsistent and unrecoverable state. Often users have to resort to business processes to reconcile the database transactions following a disaster, which a costly and error-prone process, or rely on disk replication technologies following a disaster, which may require significant time and efforts. Thus, improved methods are needed for dealing with disaster recovery.